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Abstract. BitTorrent, one of the most widespread used P2P application for file- 
04 sharing, recently got rid of TCP by introducing an application-level congestion 

control protocol named uTP. The aim of this new protocol is to efficiently use 
the available link capacity, while minimizing its interference with the rest of user 
traffic (e.g., Web, VoIP and gaming) sharing the same access bottleneck. 
In this paper we perform an experimental study of the impact of uTP on the 
torrent completion time, the metric that better captures the user experience. We 
run BitTorrent applications in a flash crowd scenario over a dedicated cluster 
I ^ I platform, under both homogeneous and heterogeneous swarm population. Exper- 

h-^ iments show that an all-uTP swarms have shorter torrent download time with 

respect to all-TCP swarms. Interestingly, at the same time, we observe that even 
t/3 shorter completion times can be achieved under careful mixtures of TCP and uTP 

, traffic. 

> 1 Introduction 

00 

Though some might argue that network congestion control is a problem that has been 
Studied to death-to which we tend to agree, at least concerning the large amount of 
- , • literature on the topic-yet the network architecture and usage are undergoing profound 

changes, that make the study of congestion control issues once more necessary. 

As far as the architectures are concerned, recent research has, e.g., addressed the 
T-H TCP incast problem in data center networks. As far as the usage is concerned, we have 

lately witnessed to an explosion of new application-layer flow and congestion control 
algorithms which are usually implemented at the application-layer over either 

TCP |[T) or UDP 0[3j. Depending on the application they have been built for, these 
protocols have rather different goals that reflect deep in their design. 

In this work, we focus on the BitTorrent filesharing protocol that recently replaced 
TCP by uTfQ|4,5|, a lower than best effort protocol for data transport on top of UDP. 
uTP starts from the observation that nowadays the Internet bottleneck is typically at the 
user ADSL access link: hence, congestion typically happens between different flows 
of the same user. Moreover, since ADSL modems have rather long buffers (up to few 
seconds | |6|7| ), using TCP for non-interactive but massive data downloads has a possibly 
negative impact on interactive communication (e.g., Skype, gaming, etc.). Indeed, as 
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Notice that this new protocol has two names: uTP in the BitTorrent community [4], and LED- 
BAT in the IETF community that we may use interchangeably in the following. 



TCP fills the buffer, this self-induced congestion translates into high latency and losses, 
that possibly harms other interactive application. To avoid the troubles of self-induced 
congestion and at the same time be efficient for massive data download, uTP tries to 
limit the end-to-end delay (by reaching a fixed amount of target delay in the access 
buffer) while maximizing the utilization of the access capacity at the same time. As the 
queuing delay is bounded with uTP, this improves the user experience for interactive 
applications. 

While uTP has sound and appealing goals, it is clearly understood that users will 
be the ultimate judge of BitTorrent performance, as in BitTorrent's own words "unless 
we can ojfer the same performance [of TCP], then people will switch to a different 
BitTorrent client" |[8|. Our recent work |9 | suggests that uTP performs better than stan- 
dard TCP, as the use of uTP practically limits the queuing delay to a small target, this 
translates into faster signaling as a side effect. However, results in I^J are based on ns2 
simulation: it becomes thus imperative to assess whether the observed phenomena also 
happens in practice, which is precisely the scope of this work. 

We run BitTorrent applications in a flash crowd scenario over the Grid' 5000 plat- 
form pO) , with special attention to the main user-centric metric, the torrent completion 
time. Results of our experiments confirm our previous simulation results, in that, as 
observed in |9 1, uTP can reduce the torrent download time. 

Yet, this experimental campaign brings new insights beyond ||9|. Currently, the de- 
fault settings BitTorrent yield to the use of a mixture of TCP and uTP traffic: as such, 
in this work we evaluate how this choice performs compared to the cases in which all 
peers use only a single protocol between TCP and uTP. In this case, our experimental 
results show that completion time under heterogeneous swarms can be even lower than 
all uTP (and, clearly, all TCP) swarms. 

The remainder of this paper is organized as follows. First, Section [2] reports pre- 
liminary insights on low-level BitTorrent settings gathered from a small local testbed, 
which are instrumental to our experiments, whose results are reported in Section [3j 
Related work are then reported in Section [4j and we summarize the paper and discuss 
future work in Section |5] 

2 Preliminary Insights 

As previously stated, the uTP protocol aims at jointly (i) being efficient by fully ex- 
ploiting the link capacity when no other traffic is present, and (ii) being low priority by 
yielding to other competing traffic on the same bottleneck. Hence, in order to achieve 
both these goals, uTP needs to insert only a limited amount of packets in the bottleneck 
buffer: on the one hand, since the queue is non empty, the capacity is fully exploited. On 
the other hand, as the queuing delay in the buffer remains bounded, this doesn't harm 
interactive applications. 

uTP exploits the ongoing data transfer to measure the One-Way Delay (OWD) 
on the forward path. While measuring the OWD is notoriously tricky among non- 
synchronized Internet hosts, uTP is interested in the difference between the current 
OWD and the minimum OWD ever observed (used as an approximate reference of 
the base propagation delay). In turn, this OWD difference yield to a measure of the 



current queuing delay, that is used to drive the congestion window dynamics: when the 
measured queuing delay is below a given target delay, the congestion window grows, 
but when the queuing delay exceeds the target the congestion window shrinks. 

The impact of this new protocol on the performance of BitTorrent can be affected by 
essentially two different settings. At a single flow level, uTP is primarily driven by the 
uTP target delay setting. At a swarm level, peers relative preference for TCP vs UTP 
protocols likely plays an important role as well. Hence, before running a full-fledged 
set of experiments, we need to get some preliminary insights on the settings of the 
above two parameters. In more details, these are: (i) net.utpJarget_delay, that tunes the 
value of uTP delay of each flow, and (ii) bt.transpjiisposition, that drives TCP vs uTP 
preference of the BitTorrent client. 

To this aim, we perform a battery of tests in a completely controlled environment 
involving one seed and two leechers, all running the latest version of the uTorrent client 
available for Linux (3.0 build 25053, released on March 2011). Clients in the local 
testbed are interconnected by a 100 Mbps LAN and we use net em to emulate an access 
bottleneck on the PC running the seed, whose uplink capacity is then capped at 5 Mbps. 
The tracker is private within the testbed and is used to announce a set of three different 
torrent files having different file and chunk sizes (file size of 10, 50 and 100 MBytes, 
and chunk size of 256, 512 and 1024 KBytes respectively). 

To understand BitTorrent settings, we tweaked the default configuratiorj^ aiming 
at (i) verifying the compliance of net.utpJarget^delay to the imposed delay and (ii) 
understanding how bt.transp^disposition settings, which controls when uTP is used, 
impacts the performance of BitTorrent. 

In the case of (i) net.utpJarget_delay, usually a single experiments is sufficient to 
verify its compliance, since every flow obeys its own settings. Conversely, multiple 
experiments were necessary in the case of (ii) bt.transp -disposition, since the behavior 
of a peer is affected by the bt.transp -disposition value of other peers as well. 

In the following we summarize the most relevant findings of the local testbed exper- 
iments. Overall, in these tests we captured about 3 GBytes of packet level traces, that we 
make available to the scientific community at fTTl. The remaining of the experiments, 
performed on the Grid'5000 platform, are reported in Section[3] 

2.1 net.utp Jargetjlelay: Target delay settings 

The net.utp Jargetudelay parameter stores the value of the uTP target delay in millisec- 
onds, and its default value is equal to 100 ms as stated in the BEP29 |4|. Furthermore, 
uTP is also standardized at the IETF LEDBAT Working Group [3], which specifies 
100 ms as a mandatory upper bound value (while earlier version of the draft referred 
to a 25 ms delay target). 

Yet, the GUI of the Windows client allows to modify its default value, opening the 
way for competition between legacy applications. This behavior is confirmed by Fig.[T[ 

^ uTorrent clients store their configuration in a file which is not directly editable (as it also con- 
tains an hash value on the configuration content, performed by the client itself) and moreover 
Linux GUIs do not offer the possibility of modifying the default settings. However, the config- 
uration file format used by Linux clients is the same as the one of the Windows clients: hence, 
we used Windows GUIs to produce a pool of configuration files, that we later loaded in Linux. 
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Fig. 1. uTP Target Settings: RTT and throughput for a single flow with 
net.utp Jargetudelay=25 ms (left) and net.utp Jarget-delay=lOO ms (right). 



where we show two experiments, performed at different times, where a single uTP flow 
sends data on a 5 Mbps bottleneck, with different values of the uTP target delay. We 
see in Fig.[T]that for both target delay settings, BitToiTent is using the entire available 
capacity, and the end-to-end delay coiTesponds to the target that we set by means of the 
net.utp Jargetjdelay settings. 

As the uTP/LEDBAT specifications 1 3j4 1 refer to a mandatory target value, we com- 
ply to the standard and focus in the remainder of this paper on the study of swarms with 
the same default value for net.utp Jargetjdelay . At the same time, we point out that as a 
future work, it would be interesting to see whether, by tweaking the net.utp Jargetudelay 
value, some peers (or some applications) can gather an advantage over the rest of the 
swarm. 



2.2 bt.transp disposition: TCP vs uTP settings 

The second parameter, namely bt.transp ^disposition, controls which protocol is used 
for the incoming and outgoing data connection of the client. As reported in the online 
uTorrent manuaj^ bt.transp -disposition is a bitmask that sums up the following behav- 
iors: 

- 1 : attempt outgoing TCP connections 

- 2: attempt outgoing uTP connections 

- 4: accept incoming TCP connections 

- 8: accept incoming uTP connections 

- 16: use the new uTP header format 

uTorrent default value is 31, which means that the client will accept both TCP and uTP 
flavors, for either sending or receiving data, possibly using the new uTP header format. 

To understand the implications of bt.transp^disposition settings, we perform a num- 
ber of tests with heterogeneous settings of the client. Notice that the parameter space 
we explore and that we make available at pTj is larger than the one reported in Tab. [l] 

' http://www.bittorrent.com/help/manual/appendixa02 12#bt.transp^isposition 



Table 1. TCP vs uTP BitTorrent transport disposition. 
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Yet, for the sake of simplicity, we only report in the table the cases that we later study 
in Section [3] which akeady conveys some interesting information. Notice also that in 
all the experiments, the seed is set with the default value bt.tmnspjiisposition^'il. 

In Case 1, the two leechers A and B have different setting for the bt.transp_disposition 
parameter: more precisely, A should attempt data connection only using TCP while B 
should use uTP (and both will accept every flavor in reception). Our experiments show 
that in this scenario, peer B sends data to peer A using the uTP protocol, which is the 
expected behavior. However, peer A sends data to peer B using the uTP protocol too, 
which happens consistently over all repetitions, and irrespectively of file and chunks 
size. The reason is that when a uTP connection between B and A is opened by B, A 
can use this opened bidirectional connection to send data to peer B. Besides, as con- 
firmed by Arvid Norberg, one of the main BitTorrent developers, the uTorrent client has 
a hardcoded uTP preference, so that in case both a TCP and a uTP connection will be 
successfully established, the former will be closed and only the latter will be used. As 
we will see in Section |3] this will have some important (and beneficial) consequences 
on the overall swarm completion time. 

In Case 2, leecher A attempts and accepts only connection via TCP (as a legacy 
BitTorrent implementation would do), while leecher B maintains the default value for 
bt.transp disposition (which means to attempt and accept both protocols). In this sce- 
nario, any communication between the two peers are performed using the TCP proto- 
col, which is consistent and expected for backward compatibility with older BitTorrent 
client. 

Other cases, not shown in Tab. [T] yield to different shares of traffic between TCP 
and uTP At the same time, since the number of leechers is small, the exact value of 
the breakdown is heavily influenced by the seeder flavor as well. As such, we defer a 
quantitative analysis of such a breakdown in the next section. 

3 Experimental Results 

We now report the experimental results on the impact of uTP and TCP transport on the 
torrent completion time. We first briefly describe the Grid'5000 experimental platform 
and then focus on two case studies, namely (i) homogeneous and (ii) heterogeneous 
swarms, depending on the bt.transp -disposition settings for the leechers. 



Homogeneous settings refer to scenarios were all peers have either a TCP-only pref- 
erence (bt.transp-disposition=5, which mimic the behavior of old uTorrent versions or 
legacy applications), or a uTP-only preference (bt.transp _disposition=lQ, in case uTP 
will prevail over TCP), or are able to speak both protocols {bt.transp _disposition—'i \ , 
the current default behavior, though with an hardcoded preference for uTP as we have 
seen in Section[2]2]). 

Homogeneous settings provide a useful reference, but we must consider also exper- 
iments with heterogeneous scenarios that correspond to what is observed in the Internet 
with clients that do not support uTP at all, or that support uTP but as a fallback choice 
rather than the default one. 

We therefore investigate heterogeneous settings as well, considering scenarios with 
different ratios of peers using uTP and TCP. More precisely, we consider the case where 
peers are able to accept any incoming protocol, but have different preferences for the 
uplink protocol (bt.transp _disposition^\3 for TCP, and bt.transp _disposition—\A for 
uTP). We consider the case where preference is split 50/50, 25/75, or 75/25 to mimic 
scenarios where TCP vs uTP preferences are fairly balanced, or biased toward one of 
the two protocols. 

Notice that, while there may be several uTP implementations available, different 
BitTorrent applications use different default settings (i.e., sticking to TCP preference 
or embracing uTP) depending on the success of the new protocol (and the existence of 
readily available libraries for different operating systems). 

3.1 Grid'5000 Setup 

We performed experiments on a dedicated cluster of machines that run Linux as the host 
operating system and using the uTorrent 3.0 client as before. Hosts of the Grid'5000 
platform are interconnected by an high-speed 1 Gbps LAN, and we emulate realistic 
bandwidth restrictions and queueing of home gateways by using the netem module 
for the Linux kernel. As noted in |j3) and experimentally confirmed by ||6]|7], ADSL 
modems can buffer up to a few seconds worth of traffic: in our experiments, we set the 
buffer size B according to the uplink capacity C so that B/C — 1 second worth of 
traffic. 

We instrumented the Linux kernel to log the queue size Q in bytes and packets af- 
ter each dequeue operation, logging also the cumulative number of packets served and 
dropped by the queue. During our experiments, we disabled the large segment offload- 
ing |12J which ensured that the maximum segment size of the TCP and uTP packets 
never exceeded the maximum transfer unit (MTU). In each experiment we used the Cu- 
bic flavor of TCP, the default for Linux kernels: in reason of our previous work |[7|, we 
may expect Cubic to be more aggressive with respect to the standard TCP NewReno 
flavor, and more similar to the default TCP Compound flavor adopted in recent versions 
of Windows. 

We use 76 machines on the Grid'5000 platform and consider an Internet flash crowd 
scenario, where a single seed is initially providing all the content (a 100 MBytes file) 
to a number of leechers all arriving at the same time (and never leaving the system). 
Furthermore, each BitTorrent peer (i) experiences an ADSL access bottleneck |13j and 
(ii) congestion is self-induced by each peer and not by other cross-traffic |[3|. 



As for (i), we start by considering 3 simple homogeneous capacity scenarios in 
which we limit the leechers and seed uplink capacity to C =1,2 and 5 Mbps. For the 
sake of simplicity, as the qualitative results do not change for different values of C, in 
the following we report the results for C = 1 Mbps. While it could be objected that In- 
ternet capacity are not homogeneous, we argue that homogeneous scenarios are needed 
as a first necessary step before more complex and realistic environments are emulated. 
Additionally, the impact of heterogeneous access capacity is a well known clustering 
effect p4) , that we believe to fall outside of our main aim, i.e., the comparison of TCP 
vs uTP transport, and that can be studies with a future experimental campaign. 

As for (ii), we are forced to map a single peer on each host of the Grid' 5000 plat- 
form, as otherwise unwanted mutual influence may take place on multiple peers running 
on the same hosts. Given the number of hosts = 76 we can use, this constrains us on 
the size of the swarm we investigate. However, we prefer to take a cautious approach, 
and avoid to introduce the aforementioned mutual influence that could bias in an unpre- 
dictable way the results of our experiments (see a discussion on the conclusions). 

We repeat the experiments three times for each settings, to smooth out stochastic 
variability in the experiments due to BitTorrent random decisions (e.g., chunk selec- 
tion, choke, optimistic unchoking etc). Also, we make results of our campaign avail- 
able to the scientific community as for the local testbed at 1 11 1. Overall, the volume of 
collected data in the Grid'5000 testbed amounts to about 16 GBytes. Yet, we point out 
that, in reason of the large number of experiments and seeds, we were not able to store 
packet-level traces, but only periodic transport-layer (i.e., TCP, UDP traffic amount), 
application layer (i.e., tracker) and queuing logs. 

3.2 Homogeneous bt.transp disposition settings 

Results of the homogeneous case are reported in Fig. |2] For each metric of interest, 
the figure reports the envelope of the gathered results, i.e., the minimum and maximum 
curves over the three iterations. 

We express results in terms of (i) the cumulative distribution function (CDF) of the 
torrent completion time T, on the right plots and of (ii) the complementary cumulative 
distribution function (CCDF) of the buffer size Q of the access link of each peer, on the 
left plots. The buffer size is expressed both in bytes (bottom x-axis) and in terms of the 
amount of delay an interactive application would experience for the emulated access 
capacity (top x-axis). 

Additional details are reported in the inset of each figure, showing: (iii) the average 
E\T] and standard deviation a\T] of the torrent completion time; (iv) the byte-wise 
share between TCP and uTP, with a notation X/Y that specifies that X% (Y%) of the 
bytes are carried over TCP (uTP), with X + Y = 100%; (v) the mean queue size E[Q] 
in KBytes and milliseconds. 

In the top row we report the scenario where all peers use default settings {bt.transp-disposition=31), 
i.e., the peers are able to speak both TCP and uTP protocols. Middle plots report the case 
of an all-uTP swarm {bt.tmnsp _disposition^\Qi), while all-TCP swarms {bt.transp_disposition—5) 
are depicted in the bottom row. 

Notice that, on the long run, all swarms achieves similar efficiency: looking at the 
CDF of the buffer occupancy in Fig. |2] we can see that in roughly 80% of the time. 
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Fig. 2. Buffer occupancy CCDF (left) and Completion time CDF (right) for homo- 
geneous swarms: default settings {bt.tmnsp_disposition=3\, top), uTP only swarm 
{bt.transpjdisposition=\0, center) and TCP only swarms {bt.trampjdisposition=5, bot- 
tom). The vertical line in the Buffer occupancy plot represent the average of the queue 
length (in KB and ms). 



after a dequeue operation the queue is non-empty. That efficiency is also tied to the 
BitTorrent system dynamics (e.g., pipelining of the requests, chunk exchange dynamics, 
etc.). Also the number of packets remaining in the queue after a packet transmission 
further depends on the congestion control protocol of choice. As expected, TCP AIMD 
dynamics tend to fill the buffer, while uTP strives (and manages) to limit the queue size. 

These behaviors translate into different completion times statistics and, especially, 
completion times appear to benefit from a mixture of TCP and uTP traffic. We point 
out that, in the mixed case where BitTorrent peers are able to speak both protocols 
{bt.transpjdisposition=2>V), the following happens: two connections, a TCP and an uTP 
ones are attempted, and in case uTP is successfully opened, it is preferred over the TCP 



one. This translates into a traffic mixture where about 80% of the data traffic happens 
to be carried over uTP. 

Notice that the queue size alone cannot explain the difference in the completion 
time statistics (as otherwise, completion time in all-uTP swarms will be the lowest). 
Hence, we conjecture this result to be the combination of two effects -on the control 
and data plane- that are assisted by the use of uTP and TCP respectively. First, a longer 
queue size due to TCP can negatively influence the completion time, by hindering a 
timely dissemination of control information (e.g., chunk interest). The longer the time 
needed to signal out interests, the longer the time prior to start their download, and their 
subsequent upload to other peers (which harms all-TCP completion time). 

Notice indeed that as in the all-TCP case the one way queuing delay due to TCP may 
reach up to 400 ms on average, this entails that RTT for signaling exchanges may be on 
the order of a second, that can possibly slow down significantly the chunk spreading 
dynamics. Consider then that BitTorrent is using pipeling to avoid a slowdown of the 
transfer due to the propagation delay of requests for new chunks. From our experiments, 
it appears that the pipelining used by BitTorrent is not large enough to deal with delays 
that might be encountered with xDSL connections. 

However, as previously said, the completion times statistics are not fully explained 
in terms of the queuing delay (as otherwise all-uTP swarms should be the winner). 
Yet, while uTP limits the queue size, and as such it avoids to interfere with a timely 
dissemination of control messages, uTP is by design less aggressive than TCP. It follows 
that TCP may be more efficient for rapidly sharing chunks in the data plane. This can in 
turn harm the all-uTP completion time, that is slightly larger with respect to the default 
settings bt. transpjdisposition—3 1 . 

Interestingly, our previous simulation study 1 15 1 shown that a combination of TCP 
and uTP can increase the efficiency on the case of two flows sharing a bottleneck link. 
Shortly, this happens because the low-priority protocol is still able to exploit the capac- 
ity unused by TCP (as its rate increases when queuing is low), without at the same time 
increasing the average system queueing delay (as its rate slow down when TCP one 
increases). The experimental results of this work further confirm that a combination of 
TCP and uTP can be beneficial to the completion time of the whole swarm as well. 
Moreover, although the exact shape of the completion time CDFs differ across experi- 
ments (due to the stochastic nature of BitTorrent chunk scheduling and peer selection 
decisions), the results are consistent across all iterations. 

Unfortunately, latest versions of uTorrent do not allow to export chunk level logs, 
which could bring further information as the trading dynamics between peers, that re- 
mains an interesting direction for future work. 



3.3 Heterogeneous bttransp -disposition settings 

Having seen that a mixture of TCP and uTP protocols can be beneficial to the comple- 
tion time, we further investigate different shares of TCP (bt.transp_disposition— 13) vs 
uTP peers {bt.transp_disposition=\A), i.e., peers that prefer one of the two protocols for 
active connection open, but that can otherwise accept any incoming connections. 

We consider three peer- wise shares, namely 25/75, 50/50, and 75/25 (in the X/Y 
notation, X% represents the percentage of peers preferring TCP on their uplink, i.e.. 
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Fig. 3. Buffer occupancy CCDF (left) and Completion time CDF (right) for hetero- 
geneous swarms: prevalence of TCP peers (75/25, top), fair population share (50/50 
middle), and prevalence of uTP peers (25/75, bottom). 



bt.tmnsp _disposition=\3). These shares represent three different popularity cases of 
uTP, that can be either the default in only few implementations of the BitTorrent appli- 
cations (25/75), or compete equally (50/50) or even be dominant (75/25). We believe 
these shares to represent illustrative points, covering all relevant scenarios of the possi- 
ble population repartition. 

The plots in Fig. [3] additionally report (i) the average queuing delay, for all the 
swarm as well as for different peer classes, (ii) the peer- and byte-wise traffic shares, 
and (iii) the average system completion time, as well as the average completion time 
for peers of different classes. 

As for (i), notice that the average queuing delay statistics are as expected, with an 
increase of the queuing delay of uTP peers due to bursty acknowledgements in reply to 
TCP traffic due to TCP peers in the reverse path. As for (ii), notice that the byte-wise 
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Fig. 4. Completion time as a function of the TCP vs uTP byte- wise share (left) and as a 
function of the average buffer size (right). 



share closely follow the peer-wise share. Finally, let us focus on (iii) the completion 
time statistics. Interestingly, as Fig. [3] shows, while a small amount of TCP traffic is 
beneficial in reducing the overall swarm completion time, a large TCP amount can 
instead slow down the torrent download for the whole system. 

Further, notice that completion times are practically the same for uTP and TCP peers 
(with a slight advantage for the latter). Hence, differently from our previous simulation 
work Q, we do not observe an unfairness of completion time between different peer 
classes within an heterogeneous swarm. This is due to the fact that |9| considered a 
simpler model for bt.transp^disposition, that neither (i) accounted for TCP peers using 
an already opened uTP connection in the reverse side nor (ii) for the hardcoded uTP 
preference. 



3.4 uTP vs TCP in a nutshell 

Fig. [4] present a summary of our results considered so far. T is the completion time 
(mean and standard deviation) for different iterations with both homogeneous and het- 
erogeneous swarm populations. The T metric is reported as a function of the byte-wise 
TCP traffic share (left plot) and of the average buffer size (right plot). 

Both plots also report, for TCP traffic shares different from zero (non-0 TCP) only, 
a linear regression of the completion time. Notice that the linear model provides a nice 
fit to forecast the completion time performance in presence of different TCP vs uTP 
mixtures. 

Furthermore, as observed in |9j by means of simulation. Fig. |4] confirms that the 
completion time increases for increasing buffer sizes, which in turn generally increases 
with the amount of TCP traffic exchanged. 

As previously argued, this is due to a slow-down of BitTorrent signaling traffic, 
while the completion time increase of all-uTP swarms is instead likely due to the low- 
priority of uTP in the data plane. Hence, we also remark a non-monotonous behavior 
for the completion time, that decreases for decreasing percentages of TCP traffic, and 
then increases again for all-uTP swarms. As different dynamics takes place, hence the 



linear dependence only applies in case of uTP and TCP traffic mixtures (i.e., non-0 TCP 
traffic share). 

Finally, notice that the default BitTorrent settings consistently yield to the shortest 
download time we observed in the experiments, which confirms the soundness of the 
bt.transp disposition design decision and settings. 



4 Related work 

Two bodies of work are related to this study: on the one hand, we have work focusing 
on congestion control aspects p]|2| |T6}|TF) , and on the other hand work focusing on 
BitTorrent l|7l|9][l4)[l5][l^|23|. 

First, congestion control literature already proposes several protocols aiming, as 



LEDBAT, to achieve lower-than-TCP priority, of which TCP-LP 1 17], NICE ||T6|, 4CP |[TF 
are notable examples. Yet, we pinpoint a recent tendency toward moving congestion 
and flow control algorithms /rom the transport layer to the application layer, of which 
uTP Q for background file-sharing, Skype |2| for interactive VoIP and YouTube |[T] 
for interactive VoD are again notable examples. Unlike transport-layer congestion con- 
trol, that applies to classes of applications, these application-layer congestion control 
protocols are usually built for single applications, with specific requirements in mind: 
these "one of a kind" deployments will in our opinion need further attention in the 
future. Recently LEDBAT also got the attention of Apple's developers, resulting in a 
implementation for MAC OS, whose preliminary tests are available at p4[ . 

Second, BitTorrent literature dissected many aspects of this successful P2P protocol, 
from the pioneering time of |19|. While our own previous works, such as ll^^Oj, al- 
ready study BitTorrent download performance by means of either passive measurements 
or experimental tests (as in this work), however they report on performance at a time 
when BitTorrent was using TCP, and should thus be updated in light of BitTorrent recent 
evolution. More generally, though related work on uTP exists |[7][9] [T5|[2T||2T] - 23 25 1, it 



does however adopt a congestion control perspective (with the exception of ^91). In 
particular, an experimental approach is adopted in ||6][7][2T[: pT] attacks the prob- 
lem of clock drift in uTP, while |]7| performs a black box study of initial proprietary 
versions of the protocol and fS^ focuses on the interaction of uTP and active queue 
management techniques that are becoming commonplace in modern home gateways. 
A simulative approach is instead adopted in 1 15j 22 23 25]: a fairness issue of uTP is 



revealed in [15] and solved in |22|, while ||23j compares the level of low -priority of 
TCP-LP 1 17 1, NICE 1J_6 1 and uTP [3], and finally pSi investigates poHcies for dynamic 
parameter tuning. 

The only previous work addressing the impact of uTP on BitTorrent completion 
time is our own recent work |9|, that however employs ns2 simulations unlike in this 
work. Interestingly, some of the observations of this study are in agreement with Q, 
e.g., showing a larger completion time for increasing buffer occupancy on the data 
plane. Yet, we point out that |9| does not consider an hardcoded preference for uTP, nor 
bidirectional uTP connections: hence, an interesting difference with respect to the cur- 
rent work is that |9| forecasted heterogeneous performance for heterogeneous swarms 
(i.e., larger completion time for TCP peers) that we have shown not to hold on practice. 



5 Conclusions 



This work assess the impact of uTP (the new BitTorrent congestion control algorithm 
for data exchange) on the torrent completion time (the main user QoE metrics) by means 
of an experimental campaign carried on in a fairly large scale controlled testbed. 

Our results show that, in flash crowd scenarios, users will generally benefit of a 
mixture of TCP and uTP traffic, both in homogeneous and heterogeneous swarms. In- 
terestingly indeed, results with mixed TCP and uTP traffic show consistently shorter 
download time with respect to the case of homogeneous swarms using either an all- 
TCP or an all-uTP congestion control. Especially, our results confirm the soundness of 
default BitTorrent settings, that yield to the shortest completion time in our experiments. 

This results is the combination of two effects, on the control and data plane, that are 
assisted by the use of uTP and TCP respectively. By keeping the queue size low, uTP 
yields to a timely dissemination of signaling information, that would otherwise incur 
in higher delays due to longer queues building up with TCP. At the same time, by its 
more aggressive behavior, TCP yields to higher efficiency in the data plane, that results 
in more timely dissemination of chunk content. 

This work leaves a number of interesting points open, that we aim at addressing in 
the future. First, we would like to investigate whether it would be possible to extend the 
swarm size by running multiple peers per machine, without however incurring in a bias 
due to the mutual interaction of the traffic injected. Second, we would like to study the 
impact of heterogeneous target values in the swarm (i.e., to see whether fairness issues 
can possibly arise) and refine our experimental setup (e.g., including heterogeneous ca- 
pacities, peer churn, etc.). Third, on a longer timescale, we aim at developing a passive 
BitTorrent inspector, capable of parsing traffic to produce chunk-level logs, that would 
greatly enhance our analysis capabilities. 
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